在线人数突破千万,B站活动保障的高效 SRE 之路!
✦✦
作者简介
武安闯
哔哩哔哩在线业务SRE负责人
2016年加入B站,深度参与B站微服务拆分、云原生改造、高可用建设、SRE转型和稳定性体系落地等项目。当前主要关注B站在线业务的SRE稳定性体系建设和推广,对SRE的实践有深入的探索与思考。
01 背景
02 活动场景
在SRE的某次活动保障时,峰值流量已成功过去,活动保障进入收尾阶段,大家已经准备收拾东西下班了。突然多个服务发生报警,服务不可用。SRE紧急介入排查,发现是活动后运营做了一个推送,导致用户集中去访问一个非活动链路中的服务,此服务未纳入活动保障中,导致容量过载,服务不可用。
还有非常多类似的案例。所以对SRE来说,为了能成功的保障一场活动,除了技术上的保障和跟研发沟通外,还要主动跟运营、产品确认活动形式、玩法、外宣方式等,SRE得离业务近一点。SRE目前会收集活动如下的信息:
活动形式
活动的具体玩法是什么:是一个直播间、还是一个秒杀、还是一个互动等,不同的玩法所需要重点保障的业务场景完全不一样。
重点场景
同一个活动,但重点场景可能不一样。比如某一场直播的重要场景是在线人数和弹幕,但另一场直播的核心可能是用户送礼和抽奖。 了解重点场景,可以指导SRE后续跟研发共建服务端保障的重点预估在线人数。
预估在线人数
活动本次预估在线人数是多少,如何预估出来的。 有哪些在线人数转化的路径。
活动对外链接
WEB、APP内的活动入口是什么?
站外有哪些引流入口?
了解用户访问路径,SRE才能做到全链路的可用性保障。
活动推送
活动中一共有几次推送?推送的形式是什么?用户转化率是多少?
活动后场景
活动结束时有没有特殊行为,比如直播间自动跳转点播页面? 活动后有什么运营事件、有什么二次热点? 这些事件所对应的用户访问路径和服务都需要SRE去重点保障,不然会有始无终,顾头不顾尾(这都是血泪的教训)。
时间线
活动前期上线、外宣、预热的时间线。
活动中的开始、推送、抽奖、口播、结束等时间线。
03 资源准备
基础资源
DNS
DCDN(动态CDN)
静态CDN带宽
直播弹幕带宽
高防
源站四层LB
源站七层SLB
WAF
IDC-云专线带宽
IDC间专线带宽
NAT带宽
网络硬件带宽
日志/监控
日志/监控:活动期间大家格外关注监控数据,需要基于监控数据来执行预案,所以监控的保障非常重要,需要纳入SRE的管理;日志类似,活动期间,查询各种数据,用户行为,业务异常等,也需要日志系统稳定。 网络硬件带宽:因为活动中业务流量突发,历史活动中曾出现过网络硬件设备带宽被突发打满的情况。所以对于业务的核心链路(机房入口—> 业务API GW —> 存储类服务 —> 基础设施)来说,确认这一步也非常有必要。
基于上面这些资源,会按如下的格式来确认信息:
使用容量和对应时间点 目前的使用水位 是否扩容、原因 弹性扩容方案、排期 扩容后水位 活动中容量预案 活动结束后方案 负责人
如下表:
业务资源
PAAS(容器资源)
IAAS(裸跑物理机资源)
CACHE中间件
MQ中间件
KV 存储
DB 存储
04 压测&演练
性能压测
第二轮:资源交付、业务扩容、服务优化后按活动目标压测(每个活动都会有这一轮)
第三轮:所有优化方案和保障方案上线后,再次压测,验证预案的有效性和服务最终能力,这次之后非必要需求不上线
第一轮:
关注压测工具、压测链路是否稳定,是否满足活动压测需求;如压测肉鸡扩容;调整限流,以免拦截压测流量。
发现有性能瓶颈的服务、接口,跟研发一起分析瓶颈点。
确认中间件是否有性能瓶颈,如Redis 热KEY,DB 热点SQL。
发现跨部门上下游服务链路中的瓶颈。
第二轮:
关注活动目标是否可以达到。
关注基础设施资源容量水位,确保安全。
关注业务资源情况,确保安全。
关注全链路上下游服务的瓶颈、中间件瓶颈。
服务框架配置一个活动预期流量的限流阈值,基于活动实际峰值压力再动态调整。 API GW配置一个比服务框架宽松但保证服务不会过载的限流阈值。 SLB配置一个保护API GW的限流阈值,一般是API GW限流阈值的两倍以上。
第三轮:
第三轮压测不是必须的。对于有第三轮压测的业务,常见场景有三种:
比如S11,有1/8决赛,1/4决赛,根据前面比赛的真实数据,再次预估线上系统的总决赛压力,对线上的系统做压力复核,同时也验证总决赛前业务上线的需求性能。 在线上的各种保障方案上线后,再次压测,确保系统运行符合预期,如:HPA能自动扩容,各种限流可以生效,多机房分流符合预期等。 对服务做极限压测,观察服务的极限瓶颈,评估业务系统预期能支持的极限在线人数。
如果业务支持的在线人数上限比较高,会给业务设置一个超出预期在线人数的限流配置。
演练
节点级故障:既支持PAAS环境的K8S节点,也支持裸跑业务的物理机 IAAS环境。 硬件资源争抢:节点上的CPU负载、内存占用、磁盘占满、网络异常 上下游故障:服务间调用延迟、丢包、失败 中间件故障:服务调用中间件,如CACHE、KV存储、DB、MQ等延迟、丢包、失败
直播业务S11核心场景故障演练 UGC业务场景对中间件依赖故障演练 OGV业务场景上下游应用依赖故障演练 消息队专项故障演练 电商业务场景的自动化故障测试 ……
服务对下游服务应该是弱依赖,但编码成了强依赖 服务调用下游服务失败后,熔断或降级方案未按预期生效 服务调用缓存超时或异常时,接口失败,导致用户请求失败 服务调用消息队列失败,导致用户写操作失败 ……
对于大型活动场景,我们所演练的故障场景也比较类似,如下:
服务上下游调用失败
服务间的强弱依赖是否合理,降级、熔断机制是否生效。服务对中间件的调用失败
对中间件是否具有降级方案,降级方案是否生效。服务所在宿主机节点故障
验证服务是否具有状态,是否可接受单点故障。服务POD故障,POD里的某个sidecar故障
验证平台的failover能力是否符合预期,主容器对sidecar的依赖是否合理。服务POD的CPU负载注入
验证服务的HPA策略是否生效,HPA策略是否合理。
05 以史为鉴
在梳理我们的保障能力之前,SRE会先检查《以史为鉴》环节的内容。
之前活动压测遗漏了WEB端的服务链路,确保以后不会再犯。
活动期间,在离线混布没有关闭,对在线服务的突发有一定压力。
以后活动时,要把在线核心业务场景的机器离线混布任务关闭。
活动期间关闭K8S的VPA策略,避免因为活动中服务压力增加,导致第二天服务的request增加,资源池无资源可调度。
活动核心链路上有服务未开启HPA,导致活动中需要手动扩容,效率较低。
……
06 技术保障
DCDN
CDN缓存
如果业务可接受一定的数据延迟,可在DCDN上添加接口缓存,降低源站服务压力和带宽,如视频弹幕列表、直播礼物道具等。
多活服务的多机房分流
七层SLB
全局限流
△ 前面有提到SLB的限流能力主要是为了保护业务API GW不过载。对于没有API GW的服务,SLB限流直接保护服务不过载。
多活服务故障自动降级
△ 如果在DCDN层面切量,是需要手动执行切量操作的,目前执行时间在5分钟左右。
△ 为了实时止损,SLB会发现服务所有机房的节点,如果某个机房的节点无法处理请求时,SLB会把请求自动降级到其他多活机房/可用区。
这种降级能力目前需要手动开启,适用于完整实现了同城双活的服务。 对于活动场景的核心请求,SRE会跟研发提前沟通,在SLB上配置此降级能力。 此自动降级功能后来也做到了API GW的功能里,实现原理比较简单,如下:
WAF
单IP限频率
恶意IP封禁
PaaS
HPA横向扩容:Horizontal Pod Autoscaler
△ 有些活动的时间会比较长,流量增长比较平缓,比如直播LOL赛事,就很适合添加HPA策略,让服务容量根据压力动态伸缩。
△ 有些活动场景,比如电商手办的秒杀,活动持续时间是秒级,可能活动已经结束了,但HPA还没扩容生效,这种场景就不适合HPA。而是应该提前扩容容量,配置好限流阈值,做好容量保护。
VPA纵向扩容:Vertical Pod Autoscaler
△ 正常情况下,在线业务资源使用率是较低的,峰值CPU使用率不会超过40%。只要资源池整体CPU使用率是安全的,我们就可以动态调整服务的request,释放出资源给其他服务调度,这就是超分/超卖的逻辑。
△ 前面有提到SRE的容量管理系统,此系统同样支持对PaaS服务的VPA管理和动态执行,一条VPA策略的核心配置例如:选定一批服务,基于此服务过去1天cpu使用量的99分位值,设置cpu_used / cpu request * 100% = 50%;此策略可立即下发生效。
△ 只要资源池总体CPU使用率水位是安全的,SRE就可以在服务无资源可调度时通过VPA能力快速释放可调度资源,大大提升了SRE容量治理的灵活度和控制力。
混合云
△ 如果资源池总体CPU使用率水位已经达到50%,此时不宜再用VPA能力继续超分。
△ SRE会给业务预留一个基于云K8S的资源池用作兜底扩容。如果IDC内的资源池容量不足,可10分钟实现云K8S节点初始化并加入云资源池提供调度。
Cache
容量保障
△ 如果需要紧急扩容,SRE建议临时增加单节点内存大小,尽量避免扩容节点。Redis扩容节点时Slot的迁移对业务有轻微的影响。
热KEY、大KEY监控
△ 如果服务直连了Redis,可通过Redis平台临时采样抓取一段时间内的请求来分析热KEY和大KEY。
DB
服务降级
在主从延迟比较大的时候(大于 120 秒) 触发 DBA 的自动降级保护逻辑,牺牲一部分宕机场景的数据一致性( 最大 1s),来提高从库性能。
异常拦截
负载均衡
监控大盘
SRE跟监控、业务研发一起,做了活动全链路监控Dashboard,一般包含业务大盘数据、基础资源容量、业务监控、中间件监控等数据,内容会随着具体活动而微调。 此大盘在活动现场保障时会用于现场投屏,大家一起紧盯监控大盘里的异常。
07 预案能力
业务熔断、降级、限流等高可用类的预案 活动玩法、功能降级等产品体验类预案
概率:TOP3类故障场景的预案优先 生效时间:生效时间越快,止损效果越好 是否有损:预案是否对业务有损,优先损失较小的预案 复杂度:预案执行的复杂度 幂等性:预案多次执行的结果是否一样,优先选择不确定性较小的预案
08 复盘改进
一、项目目标
本次xx活动,SRE团队的目标是:
首先,xx活动不能出现主流程事故。
其次,相关业务都不能出现主流程事故。
再者,不能出现基础技术事故。
用于后续活动中SRE做容量预估。 基于数据曲线挖掘活动中的一些预期外行为,如带宽突刺,流量突刺等。
四、问题复盘
这个阶段,SRE会记录活动中出现的问题,并做复盘总结,确定后续改进方案。活动保障中所产生的Todo,SRE会专项跟进,定时确认进度,确保优化方案都执行落地。
五、反思总结
09 总结展望
还不过瘾?还想了解更多B站 SRE 落地方案?与老师进行面对面交流?
GOPS 全球运维大会 2022 · 深圳站,武安闯老师将与您面对面交流。
近期好文: